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3 SPECIFICATION 

4 To all whom it may concern: 

5 Be it known that John K. Thomasson and Myron L. Mosbarger, citizens of the United 

6 States of America, have invented a new and useful invention entitled METHOD AND SYSTEM 

7 FOR ASYMMETRIC SATELLITE COMMUNICATIONS FOR LOCAL AREA NETWORKS 
€1 8 of which the following comprises a complete specification. 
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1 METHOD AND SYSTEM FOR ASYMMETRIC SATELLITE 

2 COMMUNICATIONS FOR LOCAL AREA NETWORKS 

3 

4 Software Appendix . This specification includes a software source code appendix which 

5 includes the computer source code of one preferred embodiment of the invention. In other 

6 embodiments of the invention, the inventive concept may be implemented in other computer 

7 code, in dedicated electronic hardware, in a combination of these, or otherwise. This software 

8 appendix is hereby incorporated in this application in its entirety and is to be considered to be 

9 part of the disclosure of this specification. 

rj° 

fl 1 I. BACKGROUND OF THE INVENTION 
yl2 A. Field of the Invention . 

013 This invention relates to methods and systems for communications between computers 

N14 and other digital information devices. More particularly, this invention relates to 

15 communications between computers making use of digital satellite communications channels and 

16 computer local area networks, to provide access to the internet, to facilitate data and software 

17 distribution, and/or to enhance the capabilities of intranet systems for computers with 

18 connections to local area networks. 

19 B* Description of Related Art 

20 It is well established that computers can communicate across local or wide area networks. 

21 It is also well known that satellite receivers and transmitters can be used to transfer high volumes 

22 of digital data. Some efforts have been made to provide communication systems which can be 
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1 used to transfer data between computer processors using a variety of communication mediums 

2 (see Moura et al., U.S. Patent No. 5,586,121). However, it is desirable to provide a high-speed, 

3 low-cost, satellite-based communication system which is designed to optimize the use of digital 

4 satellite systems for local area networks (LANs). Optimizing the use of the digital satellite 

5 channel is best accomplished through the use of asymmetrical communications between the 

6 computer server and the internet as opposed to symmetric communication, in which substantially 

7 the same data rates and the same media are used for both the transmit direction and the receive 
O 8 direction, and as opposed to communication system which employ asymmetrical communication 
i-v 9 between the local area network and the server. Particulary, asymmetrical systems which require 
,10 upstream router hardware, "backbone" network hardware, or dial-up internet service providers 
y. 1 (ISPs) to create a "hybrid" asymmetrical local system with a symmetrical local area network. 

r| 2 Since calls to the internet can efficiently be made at relatively low speeds, and since using digital 

£ : i 

[U3 satellites as a communication medium provides the capability of very high speed responses from 

04 the internet, an asymmetric transmission from the internet across the digital satellite to the LAN 

15 server provides the greatest system efficiency. 

16 The most common method of sending and receiving computer information today is a land 

17 line service (i.e., a switched service, a dedicated line, and/or an analog modem, each using 

1 8 telephone wire lines). However, such a system encounters may problems, including slow 

19 transmission speeds, high access costs, lack of available wire lines, and internet congestion. 

20 Satellite communication receivers are commonly used to create or supplement existing 

21 private wide area data and video networks. When used as an extension to a data network, these 

22 satellite links may interconnect local area networks. Satellite links can provide many advantages. 
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over land line service, including potentially high speed data transmission and wide availability. 
However, typical satellite links have required expensive hardware both to transmit and to receive 
data. The expense of the hardware has made the use of satellite communication channels 
generally unavailable to those who most need it. 

This invention addresses these issues by providing a method and system for providing the 
advantages of satellite communications for high volume download data packets and typically 
using a relatively low speed land line for the low volume upload data request packets. By 
capitalizing on the asymmetrical nature of internet dataflow, this invention provides an efficient 
solution for LAN to satellite internet communications. 

For general background material the reader is directed to U.S. Patent Nos. 5,095,480, 
5,379,296, 5,423,002, 5,488,412, 5,534,913, 5,539,736, 5,541,911, 5,541,927, 5,555,244, 
5,583,997, 5,586,121, 5,594,872, 5,610,910, 5,610,920, 5,631,907, 5,659.692, 5,668,857, 
5,673,265, each of which is hereby incorporated by reference in its entirety for the material 
disclosed therein. 

II. SUMMARY OF THE INVENTION 

This invention is a method and system for efficiently communicating between networked 
computers using a high speed satellite Communications channel. It is an object of this invention 
to provide a high speed satellite based information delivery system for local area network 
connectivity to the internet, for file, data, software, and/or multimedia distribution. 

It is a further object of this invention to provide a data transmission system particularly 
well suited to remote location and/or locations where access to high speed data mediums is 
unavailable or prohibitively expensive. 




1 It is a further object of this invention to provide a high speed data transmission system 

2 that utilizes a highly flexible and adaptable software method. 

3 It is a further object of this invention to provide a high speed data transmission system 

4 that communicates with the internet while being internet service provider (ISP) independent. 

5 It is a further object of this invention to provide a high speed data transmission system 

6 that makes use of digital satellite communications technology to enhance data bandwidth, 

7 channel reliability, and accessability. 

4 1 8 It is a further object of this invention to provide a high speed data transmission system 

■J3 

rf 9 that utilizes a software method capable of operating on a wide range of server operating systems, 

JlO including Windows 95, Windows NT, NetWare, Linus, Macintosh, present and future versions 

rA 1 and the equivalents. 

C|2 It is a still further object of this invention to provide a high speed data transmission 

ty 

013 system that is compatible with a wide range of communication protocols and/or mediums, 

EH 

□4 including ISDN, Tl, modem, dedicated phone line, switched phone line, frame relay and ATM. 

15 It is another object of this invention to provide a method for permitting many client 

16 computer systems, which may be operating system independent and operating on one or more 

17 local area networks, to communicate over a single satellite dish, at very high data rates. 

18 It is a further object of this invention to provide a method using software which can 

19 operate on a wide variety of hardware, operating system, and software platforms, including, but 

20 not limited to: Macintosh, Linux, Unix, OS/2, and Windows NT. 

21 These and other objects of this invention are readily apparent to individuals of ordinary 

22 skill in the art upon further study of the drawings, detailed description, claims and abstract that 
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1 are included in this patent disclosure. 

2 III. BRIEF DESCRIPTION OF THE DRAWINGS 

3 Figure 1 depicts a top level rendering of the major component parts of the communication 

4 system invention. 

5 Figure 2 depicts a preferred embodiment of the architecture of the invention. 

6 Figure 3 depicts the preferred flow of data through the several protocol transitions in a 

7 preferred embodiment of the invention. 

^ 8 Figure 4 depicts a top level flow diagram showing the primary steps of the process flow 

15 5 

Tz 9 for an example single received data packet in the preferred method of the invention. 

T"~" 
%\ 

^jLO Figure 5 depicts a detailed flow diagram showing the package delivery major step of the 

ml 1 preferred embodiment of the invention. 

CI2 Figure 6 depicts a detailed flow diagram showing the internet protocol (IP) major step of 

Hi 3 the preferred embodiment of the invention. 

01 

p44 Figure 7 depicts a top level flow diagram showing the primary steps of the process flow 

15 for an example transmission of internet protocol datagrams. 

16 Figure 8 depicts additional detail showing the transfer queue (TxQ) thread processing of 

17 the filter queue step of the transmission portion of the invention. 

18 Figure 9 depicts additional detail showing new queue (NewQ) thread processing of the 

19 filter queue step of the transmission portion of the invention. 

20 Figure 10 provides an example embodiment of the user interface of the invention. 

21 IV. DETAILED DESCRIPTION OF THE INVENTION 

22 This invention is a system and method for asymmetric communications, between a 
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1 remote information provider and a client computer system residing on a local area network 

2 (LAN), using high bandwidth digital satellite communication channels. The preferred 

3 embodiment of the method of the invention is performed in software residing on a local 

4 computer system. The current preferred embodiment of the method software in written in Intel 

5 386 assembly code, C and C++ computer languages. The reader is directed to the appended 

6 computer software appendix for a complete disclosure of the software making up the current best 

7 mode of the method of this invention. Alternatively, those of ordinary skill in the art could 

^ 8 practice this method in a wide variety of procedures, computer languages, or even in dedicated 

y[ 9 electronic hardware. Therefore this patent should not be read to be limited to the specific 

~ jO embodiment of the provided software appendix. Rather, this software source code is provided to 

H|l 1 fully describe one preferred embodiment of the method of this invention. Also, in its preferred 

£12 embodiment, this invention performs in association with DirectPC satellite receivers, Novell 

nil 3 NetWare network software, and standard off-the-shelf computer hardware. Other alternative 

ul 

^14 satellite receiver systems, networking software and computer hardware could easily be 

15 substituted by those of ordinary skill in the art without departing from the essence of this 

16 invention. Similarly, the preferred embodiment, described in the following detailed 

17 description, includes a number of components and method steps which may not be absolutely 

18 necessary in other embodiments of the invention. The reader is, therefore, directed to the claims 

19 for a description of the range of this patent. 

20 Figure 1 depicts a top level rendering of the major components and communication paths 

21 constituting the system 100 of this invention. A client computer lOla-g is shown clustered with 

22 other client computers on a local area network (LAN) 102. The client computer 101 uses 

7 



1 standard off-the-shelf commercially available software, while the server provides the user 

2 interface to the desired information. The LAN 102 provides the means for communicating from 

3 the client computer 101 to a server 103, which provides the communication interface outside the 

4 LAN. The server 103 receives data from a digital satellite receiver 1 10, depicted here as a 

5 satellite dish, across a signal antenna waveguide 1 15. The digital satellite receiver 1 10 receives 

6 the digital information from a downlink channel 111, which is transmitted from a 

7 geosynchronous satellite 1 12. The satellite 1 12 receives the information from a network 
Q 8 operations center 1 14 via an uplink channel 1 13. The server 103 generally uses the above 

9 described communications channel from the network operations center 1 14 for downloads of 

l0 information, such as internet web page data, software updates, data file distributions and other 

1 similar data packages. Alternatively and in addition, this invention provides the capability of 

l~|2 using another satellite communication channel to send requests from the client computer 101 to 

fil3 the network operations center 1 14. This is a particularly useful feature for access from remote 

Q4 locations. Use of the satellite communication channel provides important benefits to the 

15 information requestor at the client computer 101, including very high speed data transfer, the 

16 ability to receive broadcast software distributions which in turn means the requestor is likely to 

17 receive such distributions in a more timely and cost effective manner, and the ability to have 

18 internet access from locations where wired communications channels, such as telephone lines, 

19 are either unavailable, overly burdened, or prohibitively expensive. 

20 Figure 1 also shows the preferred, and more typical request communications channel. In 

21 this preferred request channel the client computer 101, connected through the LAN 102, through 

22 the server 103, sends a request via modem 105, which typically is connected to the server via a 
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1 standard serial RS-232 cable 104. The modem 105 in turn is connected to standard telephone 

2 land lines 107 via a standard phone cable 106. The request is passed across the land lines 107 to 

3 the internet service provider 108, which communicates to the internet 109. 

4 This invention is designed to be highly flexible and adaptable to different client computer 

5 101 configurations, both hardware and software as well as with and to £ wide variety of 

6 communication interfaces. Computer hardware such as personal computers, workstations, mini 

7 computers, mainframe computers and special purpose computational equipment can be 

£f 8 functional client computers 101 as intended within this patent specification. Similarly, computer 

r: 9 system operating systems which are supported and used in the preferred and alternative 

10 embodiments of this invention included but are not limited to: Windows 3. 1, Windows 95, 

M 

m 1 1 Windows NT, Macintosh, Linux, Unix, OS/2, NetWare, their current versions, past versions, and 

pl2 equivalent future versions and the equivalent. Communications interfaces that are or can 

i ' *• 

III 13 alternatively be used with or as a part of this invention include routers, ethemet, ISDN 

J-J14 equipment, switched 56, Tl, Token Ring, frame relay, modems, satellite and the equivalent. 

15 The advantage of this preferred mode of operation is that the communication channels are 

16 used in the most efficient manner. Typically, request packets are relatively small and can be 

17 transferred with minimal impact across land lines. While downloaded packets can be very large 

1 8 with significant amounts of highly concentrated graphics. For the vast majority of client 

19 computer 101 users the limitation of internet or the ability to receive other downloaded file 

20 information is the time it takes for the download transfer to be accomplished. This problem is 

21 solved by transferring the potentially very large downloaded packets (files, graphics and other 

22 information) using the high bandwidth satellite channel. 
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1 Figure 2 depicts a preferred embodiment of the software architecture of the invention. As 

2 shown, in its preferred embodiment, this software operates in association with several standard 

3 commercially available software packages and protocols, including Novell NetWare, Ethernet, 

4 Token Ring, TCP/IP, TP X and AIO. This software method of the invention also makes use of 

5 certain commercially available hardware component, as shown in figure 2, including: the satellite 

6 receiver 1 10, a network router 205 and a modem 104. The reader should understand that this 

7 figure 2 presents a single simplified embodiment of the invention. Alternative embodiments 
o 8 could use alternative software packages and protocols, as well as different or multiple hardware 
y^j 9 components. Figure 2 also shows a single embodiment of the path of information through the 

KEEK 

. J 10 various software and hardware components. Download information packets are received by the 

p 1 1 satellite receiver 1 10, which in turn communicates electronically with the DPC LAN 210, a 

a 12 commercially available hardware driver. The information next passes through the LSL NLM 

111 

ml3 202, a routine commercially provided by Novell Incorporated which acts as an intermediary 

Q 14 between the driver and the protocol stack to control information packet transfer. Next, the 

L-5. 

15 TCP/IP 203 protocol stack receives the information packet. The TCP/IP 203 protocol stack is 

16 capable of communicating alternatively with a modem 104, via the LSL NLM 202; the 

17 DPCAGENT 207 routine, core to this invention; the AIO 208, a Novell product for managing 

18 serial communications; and through the AIOCOMX 209, which is the asynchronous 

19 input/output interface to the client computer hardware communication ports, or with router 205, 

20 via the LSL NLM 202, the DPCAGENT 207, the LSL NLM 202 and an ethernet driver 204. 

21 Alternative embodiments of this invention may make use of other standard commercially 

22 available communication protocols, drivers, hardware and software. 
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1 Figure 3 depicts the flow of information in the preferred embodiment of the invention 

2 from the satellite 1 12 to the client computer 101 as well as the flow of information back to the 

3 internet 109 from the client computer 101. Data is received 301 from the satellite 1 12 by the 

4 satellite receiver 1 10. Next, the data is transmitted to and received by the server 103 hardware 

5 302 where it is placed in on-board memory. The DPC.LAN DirecPC network card driver 

6 retrieves the data packet from hardware memory 303. Next, if the packet is identified as an 

7 internet protocol (DP) format packet it is delivered to the IP protocol stack 304. If the packet is 
y 8 identified as a transmission control protocol (TCP) segment, it is delivered to the TCP protocol 
£: 9 stack 305. TCP delivers the data packet to a proxy gateway 306. The proxy gateway forwards 
% |0 the data packet to the client computer via the local area network and standard LAN protocol 

gl 1 controllers 307. Next, the client computer processes the data and generates a return packet 308. 

CI2 The return packet is delivered to the proxy gateway via the local area network and the standard 

yj 

fU3 LAN protocol controllers 309. The return packet is forwarded to the TCP stack 310, and next to 

CP 

R4 the IP stack 311. The IP delivers the return packet to the DPCAGENT.NLM process 312, which 

15 delivers the return packet data to a transmit device, such as a modem or a router 313. 

16 Figure 4 depicts a top level flow chart rendering of the major steps of the process flow for 

17 a single downloaded data packet section of the invention. Initially the downloaded packet is 

18 received 410 by the DirecPC circuit card. This circuit card next transfers the packet data to the 

19 DPC.LAN routine 402. In the preferred embodiment of the invention, as shown in the source 

20 code appendix, the DPC.LAN routine is denoted as DriverlSR proc. This process includes the 

21 steps of setting up the RAM adapters and establishing a timestamp for the packet. Further 

22 detailed information on the functioning of this routine is found within the software appendix. 
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1 Next, a test is made 403 as to whether the received data is a package delivery or an internet 

2 delivery. If the received data is package data, it is delivered 404. Package data delivery includes 

3 and provides the capabilities of simultaneously broadcasting software upgrades or data files to 

4 many client computers, potentially throughout any one continent. Client computers can also 

5 request the package data delivery service to retrieve a package of information through the client 

6 accessible interface of the invention. If the received data is internet data, then internet data 

7 delivery is made 405. Additional detail on steps 404 and 405 follows in this specification. 
^ 8 Figure 5 depicts a detailed flow chart of the preferred embodiment of the package 
j~: 9 delivery major step of the method of the invention. The data packet is transferred to the 

JO DPCAGENT,NLM process 501. This process is a NetWare Loadable Module (NLM) process 

Hi 1 running on NetWare. After the data packet is received 501, a test is made to determine whether 

CI 2 the packet will update the catalog 502. If the catalog will be updated, then it is updated 503 

Hi 3 using off-the-shelf commercially available software and the process of package delivery for that 

M4 packet ends 511. If, however, the catalog will not be updated, then a test is performed to 

15 determine whether the site will be updated by the data packet 504. Site updates include 

16 modification of such site parameters as NOC versioning, encryption key updates, and becoming a 
11 member of a group or leaving a group. If the site will be upgraded, then the process performs the 

1 8 upgrade of the site parameters 505 , and the process for this packet ends 511. If the site will not 

19 be updated, then the package file is found and stored on the server disk 506. A test is then made 

20 to determine whether the end-of-file has been encountered 507. If the end-of-file has not been 

2 1 encountered then the process for that packet ends 511. However, if the end-of-file has been 

22 encountered, then a test is made to determine whether there are any "holes" in the file, that is 
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whether the file is incomplete 508. If no holes are found in the file, it is marked as complete 509 
and the process for this packet ends 5 1 1. If "holes" are found in the file, then a request for partial 
retransmit of the missing packet is sent 510, at which point the process for this packet ends 511. 

Figure 6 depicts a detailed flow chart of the preferred embodiment of the internet protocol 
delivery major step of the method of the invention. Internet package delivery or Internet Protocol 
(IP) delivery is a major function of the invention providing the capability of receiving large files 
from an internet source at a very high speed. First the data packet is transferred to the 
DPCAGENT.NLM routine 601 . A test is made to determine whether the data is in transmission 
control protocol (TCP) 602. If the data is not in TCP protocol then the data packet is transfered 
to the Internet Protocol (IP) stack 609 and the process for this data packet ends 610. If the data is 
in TCP form then a test is made to determine if a "S YN" or beginning of section is being 
initiated 603. If no "SYN" is detected, then a test is made to determine if an end of session, 
commonly a FIN or RST command, has been encountered 605. If no such end of session is 
found, then the data packet is transferred to the DP stack 609 and the process for this packet is 
ended 610. If, however, a "SYN" is detected, then the inquiry is made as to whether a 
connection slot is available 604. Connection slots perform the function of managing the number 
of subscribers permitted to have access to the communication network at a given time. If a 
connection slot is available, it means that the customer still has client computer access capacity. 
If a connection slot is available, a connection slot is allocated 607 and the data packet is 
transferred to the IP stack 609 and the process ends. If it is determined that a connection slot is 
not available, then the data packet is dropped or discarded 606 and the process for this packet 
ends 610. 
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1 Figure 7 depicts a top level flow chart showing the primary steps of the preferred 

2 embodiment of the transmission of internet protocol datagrams (or packets) method steps of the 

3 invention. Packets that are received from the IP stack are stored on the NewQ 70L Next the 

4 packet is removed from the NewQ and tested against the each and every packet on the TxQ to 

5 determine if any TxQ data is redundant or dated and should be replaced 702. If a comparison of 

6 the packet with the TxQ packets finds the updated or "newer" information, then the TxQ packet 

7 data is replaced by the current packet data. This approach is essential to maintaining the fairness 
Q 8 of the TxQ packet transfers while ensuring that good data is transmitted thereby improving the 
039 transmission efficiency of the system. A test is performed to determine if the packet was 

-53= 

JfO included in the TxQ 703. If the packet was not included then the current or NewQ head packet is 

3 1 dropped or discarded 704. Otherwise, if the packet was included, a test is performed to 

j=42 determine if the NewQ is empty 705. If the NewQ is not empty, the process returns to the test 

J , z 

HJLi 

ff|3 NewQ step where a new NewQ head packet is compared against the TxQ. If, however, the 

f n 

C$ 4 NewQ is empty, then the process enters a wait state 706 where a trigger, that is meeting a 

15 specified condition, such as new packet on the NewQ or exit command, is required before the 

16 process restarts at the testing step 702. 

17 Figure 8 depicts a detailed flow chart showing the transfer queue (TxQ) thread processing 

18 steps of the transmission portion of the invention. In the preferred embodiment of the invention 

19 processing the TxQ and processing the NewQ are independent threads of the program which are 

20 capable of running independently on one or more computer processors. In processing the TxQ it 

21 is first determined whether the TxQ is empty 801. If the TxQ is empty, then the process enters a 

22 wait state 805 where a trigger, such as a polling timer, a transmission complete signal, or an exit 
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1 command, is required to resume processing. Note that in the preferred embodiment of the 

2 invention the expected wait time is calculated in this step and the polling time is initiated. If the 

3 TxQ is not empty, a test is made to determine if the head packet of TxQ is too old 802. In the 

4 preferred embodiment of the invention, too old is defined as a packet that has been in the TxQ 

5 for more than sixty (60) seconds. Alternative embodiments could employ any practicable time 

6 period. If the TxQ head packet is too old, then it is discarded 806 and the process returns to the 

7 TxQ empty test 801. If the TxQ head packet is not too old, then a test is made to determine if the 
O 8 media, or communication conduit, is capable of transferring another packet of data 803. If the 

yj 9 media is capable of transferring another packet, then the packet is written to the transmission 

s 

J jO device 804, otherwise, the process enters the wait state 805 and waits for a trigger as described 

L| 1 above. 

C§ 2 Figure 9 depicts a detailed flow chart showing the new queue (NewQ) thread processing 

S - X 

nJ3 steps of the filter queue step of the transmission portion of the invention. The filter queue 

CJ4 processing step of the invention, which is the core of step 702, is important in providing the 

15 communication efficiency which is one of the key objectives of this invention. A test is made to 

16 determine whether the NewQ is empty 901. If the NewQ is empty then a wait state is entered 

17 902 where a trigger, such as new packet available in NewQ, exit or timer count, is required to 

1 8 resume the process. If NewQ is not empty, then the head of NewQ is renamed as ECB 903, a 

19 packet holding variable. The maximum age of the ECB packet is set 904 and a test is performed 

20 to determine if the ECB packet is fragmented 905, that is whether ECB is only a partial packet, 

21 which in the current best mode of the invention is not inspected. If ECB is fragmented, then it is 

22 appended 906 to the TxQ for transmission. If ECB is not fragmented, then a test is performed to 
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1 determine if it is a TCP packet 907. If it is not a TCP packet, then the test is made to determine 

2 if it is a UDP packet 980. If it is not a UDP packet or a TCP packet then it is appended to the 

3 TxQ for transmission 906. If, however, it is a UDP packet, a test is made to determine if ECB is 

4 a duplicate of a DNS request 909. If ECB is not a duplicate of a DNS request, then the packet is 

5 appended to TxQ 906. If ECB is a duplicate of the DNS request, then it is discarded 910 and the 

6 process returns to testing to see if NewQ is empty 901 . If it is a TCP packet, then a test is made 

7 to determine if ECB is a "SYN" or beginning of session packet 9 1 1 . If ECB is a "S YN" packet, 
O 8 then a test of whether a connection slot is available is made 912. If a connection slot is available 
CO 9 it is allocated 913. If, however, a connection slot is unavailable ECB is discarded 910. If ECB is 
j{10 not a "SYN" packet then the test is made to determine if ECB is a session abort packet (RST) 
TTl 1 914. If ECB is found to be a session abort packet TxQ is cleared of all matching packets 915 and 
^12 a test is made to determine if ECB will terminate a session 916. If ECB is not a session abort 
fyl3 then the step of clearing all matching packets 915 is skipped. If the ECB is found to terminate a 
pi 4 session, then the a connection slot is released 917. A test is then performed to determine if ECB 

15 is void of user data 918. If it contains user data then it is appended to TxQ 906. Otherwise, the 

16 End-of- Window-Position (EOWP) is computed 919 and a test is made to determine if ECB's 

17 EOWP is greater than the matched TxQ packets 920, if not ECB is discarded 910, and if so, ECB 

18 has its EOWP stored in matched TxQ 921 and then ECB is discarded 910. 

19 Figures 10a-l show various screen shots demonstrating the user interface of the invention. 

20 Figure 10a shows the DCPAGENT routine options for user selection as well as the digital 

21 package delivery queue screen. Figure 10b shows a package of data in transit as displayed on the 

22 user screen. Figure 10c shows the main screen of the package delivery interface. Figure lOd 
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1 shows package statistics as displayed for user information. Figure lOe shows configuration 

2 control screens where the user can modify certain modem, package delivery and provider 

3 configuration information. Figure lOf shows the package delivery configuration editor screens 

4 with the information that can be user modified. Figure lOg shows the login script editor and the 

5 provider configuration editor. Figure lOh shows additional provider configuration editor screens 

6 showing the configuration of an outbound protocol case. Figure lOi shows the dish or antenna 

7 pointing adjustments screens. Figure lOj shows the satellite dish signal strength meter for dish 
I 8 alignment. Figure 10k shows the adapter information screen, here showing site information 

J 9 including the card hardware serial number, the site identification, the status of keys, and a list of 

= 10 communities or groups in which the user is participating. 
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